易用性方面，除了开发人员熟悉的应用，还有艺术家、游戏行业或芯片设计行业可能会用到的应用，例如：Helix DAM，并可以和其他的主流且成熟的第三方应用进行集成。

接下来说一下流程，大家现在已经不会去质疑CI/CD的必要性了。

软件、硬件团队交付的速度，芯片推向市场的速度，都会直接影响到收益，以及软件交付是否高效，或服务交付得是否有效，决定着这个企业的发展前景。

CI/CD已成为一种趋势，刚才几位嘉宾提到，小规模的改动，快速的迭代，有利于更小、更轻微的发布问题。但是，什么是小规模的改动？这实际是对设计的考验，而不是对CI/CD。如果架构设计得不好，那每次提交代码扫描也无法发现问题。在工程实践中，越来越多的客户把CI/CD作为必选项，在为工具选型时，客户会询问能否支持CI/CD，如果不能支持，这个工具就出局了。

说到CI/CD，必然会想到Jenkins。Jenkins本身很简单，它是社区里最常见的一种工具，作用是把流程串起来。在团队较小的时候使用Jenkins，利用它提供的许多的插件，不会产生大问题。但当团队人数上升后，例如每天要跑高负荷的流水线，Jenkins能否支撑？另外，如果始终维持一个流水线，或者是一个巨型Jenkins，往往会顾此失彼。一旦单点故障出了问题，整个团队的工作都会被迫中断。

另一种扩展方式是，拥有很多小型Jenkins，每个团队使用自己的Jenkins，这将导致企业产生审计和安全问题。使用的插件是否合规？代码的安全性能否得到保障？API的接口是否控制合理？这些都是问题。

这些是常见的使用Jenkins的缺点，开源软件没有技术支撑，Jenkins分散、隔离的部署方式无法进行共享，一个公司中拥有很多的组织，每一个组织都使用Jenkins，经验无法共享。比如A团队中，员工个人能力很强，把自动化实现得很好，写了很多很好的配置、设置，又或者是流水线。B团队稍弱一些，则没有办法轻易从A团队的知识中获益。另外是安全性、稳定性等问题。

如何解决这些问题？您需要一个统一的平台，在此平台上可以很容易的扩展，但这些扩展要在统一的管理之下。除CI外，还有效能分析。当企业使用了CI/CD或是DevOps的研发流程，就意味着使用了很多工具，如何衡量这些工具也是一个问题。在统一的平台上，CI数据较容易收集，除了基础的CI功能外，也需要提供一些分析依据。

当企业使用普通、小型的CI/CD方案遇到困难时，我们推荐CloudBees。CloudBees借鉴了K8S的思想，K8S是由控制平面管理各种各样的Pod，CloudBees是基于普通工具，它是商业版的Jenkins，能够集中管理实例。它是整个集群的控制平面，有了CloudBees，就可以实现所需，比如流水线的模板，插件的版本，都可以配置为代码，然后作为模板下发到实例里，实现完整性。另外，它有一个统一的入口，在权限管理、资源共享上，有可使用的共享工具，让共享资源更便捷。

当有了流程后，自动化程度更高产生的效果更好。比如互联网行业的自动化水平会稍高一些，因为没有硬件实体。但在传统行业，比如医疗行业或是汽车行业，CD很困难。不过没有关系，可以借鉴思路。一些常见的比如单元测试、自动化测试，可以放到流程化里，无论是嵌入式、纯软件，还是提供API的，自动化测试都可以嵌入流水线中，效率才能得到提升。除了测试，还有安全性也可以放入流水线，这也是常见做法。

使用静态扫描工具存在一个问题。传统做法中，团队负责人发话，要解决代码太烂的问题，扫描出的问题数量是天文数字，使开发团队对SAST很抵触，他需要抛开别的工作，只专注解决问题。

一个现实的选择是边写边清理。以前有问题，现在注意，以后做好就行。这样就可以先聚焦在能够处理的范围内，这让阻力小了很多。另外，质量门限进行调整时，一开始宽松，后面较严苛，阻力也会小很多。一旦持续做此项工作，只要坚持，代码库会逐渐变得干净、整洁。

比较典型的部署方式是，首先，对代码质量负责的人，在每次、每天或者是更长的时间周期中，对代码做公司统一标准门限的检查。每次提交时也可以做检查，相当于一次快速的回归，通常可以放到流程里。当报了问题，肯定需要修改，要实时得到反馈，也可以在提交前自己做检查，这就叫即时检查。这就是SonarQube的典型场景。

为什么推荐SonarQube作为静态扫描工具？因为它的部署可伸缩，为大规模团队提供负载均衡的方案。如果开发的是互联网应用，那么上述的场景均有覆盖。SonarQube天然支持29种语言，还支持服务器端分析，包括自动化构建流水线的分析，以及客户端的分析。

此流程中，用户可以在自己熟悉的环境上工作，即时分析，之后可以提交VCS。自动化构建方面，当Jenkins无法搞定这些时，团队规模较大时，可以考虑CloudBees，分析结果会反馈到SonarQube。

另外一个实用功能是，提交后被发现有问题，此问题是SonarQube发现的，它反应给版本控制系统的用户，把这个问题下推到客户的环境上，通过插件发送消息。

SonarQube自身有社区版，提供很多插件，与市面上流行的开发工具集成。另外，它的使用简单，有良好的群众基础，很多人免费使用了多年。当他们购买了商业版，就不需要寻求帮忙，因为他们之前在使用社区版。

SonarQube主要扫描自身代码，但还有一部分：那就是开源代码。以前，大部分很多代码由自己编写，用什么库都在掌控之中。现在不是，特别是JAVA项目，很多依赖，当需要一个功能时，不是自己去写，而是去搜索。但不可否认的是，将开源组件引进项目中是一个迫不得已的选择，因为时间紧、任务重，只有使用开源组件才能按时交付，但又没有足够的时间去确保它的安全。这时，小企业因为用户不多，亏得起，坏了就修。但是作为一个认真的大企业，这些问题则不允许出现，开源代码安全必须被考虑到。

首先，选用一些能够识别不同语言、不同框架的工具。现在各种各样的包管理系统多达数十种。作为互联网行业从业者，使用的开发技能非常多。

其次，和SonarQube问题类似，问题一定要分级，不能一下爆太多。被问题淹没时，只能假装没有问题，所以，只推最关键、最急迫的问题很重要。

同时，需要提供修复建议，然后是软件物料清单，还有开源合规性。现在有针对开源软件诉讼的律师，可以打官司，看开源软件使用是否合规。当公司规模较小时，使用开源组件一般不被追究。但万一某个项目成功了，带来很多收益，风险就会陡增，因此，开源组件的合规性必须要考虑。

减少技术债务，程序员需要处理的事务很多，以前的问题，比如公开发布了漏洞，或者是某些东西已经过时，要及时提醒和升级。获得的合并建议是否真实有效且合理？例如建议升级，升级完不一定解决问题，例如引入了新的问题，这也行不通的。

关于开源代码安全方面，我们推荐Mend（也就是WhiteSource），因为它实现了代码库完整的开源安全检查，集中部署，集中策略设置。

现在，左移概念很火，在提交时引入了一个新问题，能够立刻得到反馈，这样很容易找到上下文，修复起来特别快，同时提供修复建议，还有重要的一点是，Mend支持离线部署。

前面说的都是研发阶段的运营与支持，但IT运维也有敏捷的需求。我们接触过一些大厂IT的运维同事，一到公司就十分忙碌。 每一个运维都有自己的文档，或总结的经验，因为这是一个依赖于经验的岗位。软件开发已经进入DevOps时代，部署又讲云原生或者是K8S容器化部署，软件的架构越来越复杂，如果运营仍然停留在过去，就会陷入疲于奔命的状态。这时，你需要为自己争取更好的工作条件。

运营遇到的挑战是架构越来越复杂，比如去捞一个日志，传统的定位方法是有问题就拿日志来查，相对比较容易。但现在，大多部署在云上，在哪台机器上跑的业务都无从知晓，更何况从海量的数据中捞日志？时间很紧迫，工具却零零散散，支持的挑战很大，业务需求多变，一直会有各种各样的单子，一天处理几百次服务请求。

对于现在的运营与支持来说，运营与研发应该是紧密结合的。这次会议中，有人提到一个职位叫SRE，这个职位地位较高，他需要做的事情是，研发永远把运营需求的优先级排在功能需求之后。所以，必须有一个人参与这个复杂的架构，在上线前，对部署的形态等有充分了解。因此组织需要支持这个职位有一定的话语权。这样，系统上线后要监测，也能有监测的数据，出了问题能尽快恢复，把功能关掉、降级运行，或者局部把问题封锁在某一范围内，这些都是解决方案，但必须在研发阶段考虑到，否则等到运维时出了问题，就无法做到这些，甚至连监控都不行。

运营与支持的自动化水平，预定义的预警处理流程，自动化的工单优先级分级，比如问题出现，首先有告警，同时，对这些告警有预处理机制。当出现问题导致持续宕机，无法恢复时，需要根据运维人员的值班表逐级寻找解决人员，这些都是自动化的流程。

实践经验的积累、有价值的复盘文章和研发的改进都是合理的，只有把以往的经验有效沉淀，才能实现持续改进。

多渠道自服务的文化分为两点，一是用户，比如即时聊天工具，能上报问题；二是问题左移，这个组织是否是学习型的组织？是否有良好的知识共享文化？这里有零级支持的概念，一个小团队遇到问题，能够在身边快速找到相应资源解决问题，甚至没有正式上升到运维团队，这是很好的思路。

上述这些都需要开放的协作平台，让工作在团队之内可见。如果没有开放的平台，工具零散，实现起来很困难。

ITSM方面，我们推荐Jira Service Management解决方案，它包括很多产品，比如JSM是一个工单系统，可以实现工单处理自动化、多渠道的提交等。除此以外，还有预警处理，可以处理事件，分类预警，并且实现一定程度的自动化和调度等等。还有与Confluence结合使用的知识库。运营或者是支持中遇到的问题，可以和上游设计问答，或者是与项目管理进行关联，可以给上游的Jira开Ticket，列入开发人员的工作计划。

这张图总结了以上的内容，运维就是ITSM，开发就是DevSecOps流程。但这里只显示了以上提到的软件，其实还有很多其他软件，比如一些自动测试工具。上游是项目管理和设计——Jira和Confluence。

Atlassian ITSM解决方案的好处是可以轻松应对大规模团队，无论公司是10个人还是1万人，都可以使用，因为它是可拓展的。另外，Jira本身拥有强大的生态系统，不会因为买了Jira而绑定Atlassian。如果它不能满足需求，可以寻找插件的帮助，如果插件还是不能满足需求，龙智可以帮你定制开发。

以上就是我今天演讲的主要内容，分享我们做实践的具体思路，欢迎大家咨询龙智，一起交流DevSecOps心得。

谢谢大家！

如需了解DevSecOps行业最新动态与消息，请立即联系DevSecOps研发安全运营一体化解决方案供应商——龙智：

官网：www.shdsd.com

电话：400-666-7732

邮箱：[email protected]返回搜狐，查看更多